---
title: Linter
emoji: ✅
category: tools
description: How to use the Rome linter.
---

import PackageManagerRomeCommand from "@src/components/PackageManagerRomeCommand.astro";
import NumberOfRules from "@src/components/generated/NumberOfRules.astro";

# Linter

Rome's linter statically analyzes your code to catch common errors and to help writing idiomatic code.

<NumberOfRules />

## Use the linter via CLI

You can start by running the CLI with the `--help` flag:

<PackageManagerRomeCommand command="check --help" />

Which will show you the options available at the moment:

```plaintext
Run various checks on a set of files.

Usage: [--apply] [--apply-unsafe] <PATH>...

Available positional items:
    <PATH>  Single file, single path or list of paths

Available options:
        --apply         Apply safe fixes, formatting
        --apply-unsafe  Apply safe fixes and unsafe fixes, formatting and import sorting
        --vcs-client-kind <git>  The kind of client.
        --vcs-enabled <true|false>  Whether Rome should integrate itself with the VCS client
        --vcs-use-ignore-file <true|false>  Whether Rome should use the VCS ignore file. When [true],
                        Rome will ignore the files specified in the ignore file.
        --vcs-root <PATH>  The folder where Rome should check for VCS files. By default, Rome will
                        use the same folder where `rome.json` was found. If Rome can't fine the
                        configuration, it will attempt to use the current working directory. If no
                        current working directory can't be found, Rome won't use the VCS integration.
        --files-max-size <NUMBER>  The maximum allowed size for source code files in bytes. Files
                        above this limit will be ignored for performance reason. Defaults to 1 MiB
        --indent-style <tab|space>  The indent style.
        --indent-size <NUMBER>  The size of the indentation, 2 by default
        --line-width <NUMBER>  What's the max width of a line. Defaults to 80.
        --quote-style <double|single>  The style for quotes. Defaults to double.
        --jsx-quote-style <double|single>  The style for jsx quotes. Defaults to double.
        --quote-properties <preserve|as-needed>  When properties in objects are quoted. Defaults to
                        asNeeded.
        --trailing-comma <all|es5|none>  Print trailing commas wherever possible in multi-line
                        comma-separated syntactic structures. Defaults to "all".
        --semicolons <always|as-needed>  Whether the formatter prints semicolons for all statements
                        or only in for statements where it is necessary because of ASI.
        --colors <off|force>  Set the formatting mode for markup: "off" prints everything as plain
                        text, "force" forces the formatting of markup using ANSI even if the console
                        output is determined to be incompatible
        --use-server    Connect to a running instance of the Rome daemon server.
        --verbose       Print additional verbose advices on diagnostics
        --config-path <PATH>  Set the filesystem path to the directory of the rome.json configuration
                        file
        --max-diagnostics <NUMBER>  Cap the amount of diagnostics displayed (default: 20)
        --skip-errors   Skip over files containing syntax errors instead of emitting an error
                        diagnostic.
        --json          Reports information using the JSON format
    -h, --help          Prints help information


```

## Code fixes

Lint rules may provide automatic code fixes.
Rome distinguishes between two types of fixes:

- safe fixes
- unsafe fixes

Safe fixes are guaranteed to not change the semantic of your code.
They can be applied without explicit review.

To apply _safe fixes_, use `--apply`:

```shell
rome check --apply ./src
```

Unsafe fixes may change the semantic of your program.
Therefore, it's advised to manually review the changes.

To apply _unsafe fixes_, use `--apply-unsafe`:

```shell
rome check --apply-unsafe ./src
```

## Ignoring Code

There are times when a developer wants to ignore a lint rule for a specific line of the code.
You can achieve this by adding a suppression comment above the line that emits the lint diagnostic.

Suppression comments have the following format:

```js
// rome-ignore lint: <explanation>
// rome-ignore lint/suspicious/noDebugger: <explanation>
```

Where

- `rome-ignore` is the start of a suppression comment;
- `lint` suppresses the linter;
- `/suspicious/noDebugger`: **optional**, group and name of the rule you want to suppress;
- `<explanation>` explanation why the rule is disabled

Here's an example:

```ts
// rome-ignore lint: reason
debugger;
// rome-ignore lint/suspicious/noDebugger: reason
debugger;
```


## Configuration

### Enable a lint rule

Recommended rules are enabled by default and emit diagnostics with the error severity.
Rules that are not recommended are disabled by default, but they can be enabled via configuration.
The diagnostics emitted by these rules are displayed with the warning severity in the documentation.

To enable rules, you need to change their diagnostic severity based on your needs:

```json
{
  "linter": {
    "enabled": true,
    "rules": {
      "style": {
        "useBlockStatements": "error",
        "useShorthandArrayType": "error",
        "noShoutyConstants": "warn"
      }
    }
  }
}
```

### Disable a lint rule

Just add `"off"` as value inside its configuration. For example:

```json
{
  "linter": {
    "enabled": true,
    "rules": {
      "suspicious": {
        "noCommentText": "off"
      },
      "style": {
        "noUnusedTemplateLiteral": "off"
      }
    }
  }
}
```

### Change the diagnostic severity

Most of Rome's rules will emit an **error**, but you are free to change their severity.
Just add `"warn"` as value of the rule. Example:

```json
{
  "linter": {
    "enabled": true,
    "rules": {
      "suspicious": {
        "noCommentText": "warn"
      }
    }
  }
}
```

This is useful in cases there's being a refactor going on and there's need to make the CI passing.

## Rule options

A few rules have options.
When they do _accept_ some, you can pass them by shaping the value of the rule differently.

```json
{
  "linter": {
    "enabled": true,
    "rules": {
      "correctness": {
        "noCommentText": {
          "level": "warn",
          "options": {}
        }
      }
    }
  }
}
```

- `level` will indicate the severity of the diagnostic, valid values are: `"off"`, `"warn"` and `"error"`;
- `options` will change based on the rule.
